tls: ignore a late setSession() instead of aborting (SSL_set_session returns 0) - #41671

…t wraps (#37664)

### Problem
- `new tls.TLSSocket(socket)` on the client side (STARTTLS) does nothing
on main. A write throws `TypeError: socket.@Write is not a function`.
`_start()` throws `ERR_MISSING_ARGS`.
- Since #42181 (not released), `end()` throws an uncaught `TypeError:
socket.shutdown is not a function` at `endNT (node:net)`.
- Cause: the constructor stored the wrapped stream as `_handle`
(`src/js/node/tls.ts`). Nothing replaced it with a TLS handle.

### Fix
- The constructor runs the upgrade of `tls.connect({ socket })`
(`kUpgradeClientTLS`, `src/js/node/net.ts`). `_handle` is never the
stream. `_start()` is a no-op.
- The wrap completes like node's `_finishInit`: `'secure'` and
`ssl.verifyError()`. It gets no hostname check and no `'secureConnect'`,
and `authorized` stays `false`.
- Verified: `test/js/node/tls/node-tls-connect.test.ts`. 16 of its 21
new tests fail on main. Also `test/js/node/tls/` and 657 vendored node
tests.

### Background
- STARTTLS changes a plaintext connection to TLS in place. The `mysql`
driver 2.18.1 does it with this constructor. No user filed an issue for
it.
- In `node:net`, `_write`, `_final` and `_destroy` call into `_handle`
as a native handle.
- Only `tls.connect()` adds node's `onConnectSecure` (hostname check,
`authorized`, `'secureConnect'`). A wrap gets `_finishInit` only.
- Considered a start on `_start()`, as in node. Each handle call then
needs a guard.

### Downsides
- An unused wrap now sends a ClientHello of 1450 bytes (main and node:
0). `setServername()` and `setSession()` after construction have no
effect on that handshake.
- Unlike node, a wrap rejects an untrusted certificate unless the caller
passes `rejectUnauthorized: false`. An app that does its own check must
pass `false`.

<details><summary>Notes</summary>

**Scope.** This head is the core only, as the review of 2026-09-24
asked. The same review decided that a wrap rejects an untrusted
certificate by default. Two parts of the earlier head are gone, because
other changes own them. #42235 landed the forwarding of the `'error'` of
a `Duplex`, and #43791 owns it for a `net.Socket`. #38028 owns the
destroy of a wrapped socket that has not connected yet. The
`UpgradedDuplex.rs` hunk landed with #36909. The review of 2026-09-25
asked for three more changes: commits 6657bc3 and ae669bf, and
this body. The review of 2026-09-30 asked for one more: commit
a460a9d.

**Changes since the earlier head that the review did not list.**
- The `open` handler of an upgraded socket applies the `session` option
on the native socket. See "Sessions" below.
- A wrap gives the `NODE_TLS_REJECT_UNAUTHORIZED=0` warning of
`tls.connect()`.
- `authorized` and `authorizationError` keep their initial values on a
wrap, as in node. The earlier head set `authorized = true` for a good
chain. The wrap checks no host name, so that value accepted a
certificate of any host. The verdict is `ssl.verifyError()`.
- A wrap does not get `onConnectEnd`. A peer that closes during the
handshake gives `'end'`, `'finish'`, `'close'` and no `ECONNRESET`, as
in node. `tls.connect({ socket })` keeps its `ECONNRESET`.
- `servername` is passed into the upgrade. Before, it reached the
ClientHello only when the caller gave no `secureContext`.
- `kStandaloneWrap` is initialised in the `Socket` constructor.

**Differences from node v26.3.0 that stay.** The review kept the start
of the handshake in the constructor. The `mysql` driver, the main user
of this API, calls `_start()` right after the constructor, so it sees no
difference.

| shape | node | this PR |
| --- | --- | --- |
| wrap that is never used | sends nothing | sends a ClientHello (1450
bytes) |
| `setServername()` after the constructor | applies, the handshake
starts later | too late. Pass `servername` as an option. |
| `setSession()` after the constructor | applies | no effect. Pass
`session` as an option. |
| untrusted certificate, `rejectUnauthorized` absent or `true` |
`'secure'`, the caller must read `ssl.verifyError()` | destroy with the
verify error, `'_tlsError'`, no `'secure'` |
| untrusted certificate, `rejectUnauthorized: false` | `'secure'`, data
flows | the same |
| `new TLSSocket(raw)`, then `tls.connect({ socket: raw })` | `EALREADY`
on the wrap | `Invalid socket` on the `tls.connect` client (main: works,
because its wrap does nothing) |

Node never rejects a certificate on a wrap. It leaves the check to the
app, so an app that forgets the check accepts any certificate. Here the
wrap uses the rule of `tls.connect()`: it rejects unless the caller
passes `rejectUnauthorized: false`, or `NODE_TLS_REJECT_UNAUTHORIZED` is
`0`. Before commit 4d8b9e5, only `rejectUnauthorized: true` rejected,
and a wrap with default options accepted each certificate, as in node.

The `mysql` driver listens to `'secure'` and to `'_tlsError'`. If the
wrap emitted `'secure'` and then destroyed itself, the driver would
report a bad chain two times. The replay test asserts one report.

**Sessions.** BoringSSL's `SSL_set_session` calls `abort()` when the
handshake has started, in release builds too.
`TLSSocket.prototype.setSession()` calls the native function at once, on
main and on this head. #41671 puts the guard in the native function, for
each caller: a late `setSession()` then throws `Already started.`. An
earlier head of this PR made `setSession()` only store the session. The
review asked to take that rule out, and commit ae669bf did. For a
client-side wrap the review then asked for one narrow rule, in commit
a460a9d: the `TLSSocket` constructor sets `kStandaloneWrap`, and
`setSession()` returns at once when it is set.

| shape | node | main | this PR |
| --- | --- | --- | --- |
| `new TLSSocket(raw)`, `setSession()`, `_start()` | resumes | throws
`ERR_MISSING_ARGS` | no effect, full handshake |
| `tls.connect({ socket })`, then `setSession()` | no effect | process
aborted | process aborted |
| `setSession()` inside `'secureConnect'` | no effect | process aborted
| process aborted |
| `tls.connect({ port })`, then `setSession()` before it connects |
resumes | resumes | resumes |
| `tls.connect({ port })`, then `setSession()` in the `'connect'`
listener | full handshake | resumes | resumes |
| `tls.connect({ socket, session })` | resumes | full handshake |
resumes |
| `new TLSSocket(raw, { session })` | resumes | throws
`ERR_MISSING_ARGS` | resumes |

In the first row, the wrap has sent its ClientHello when `setSession()`
runs. Without the check in `setSession()`, that row aborts the process
(exit 134). The rule also holds for a wrap over a socket that is still
connecting: node resumes there, and this PR runs a full handshake.

The last two rows come from one hunk that stays. `SocketHandlers2.open`
applies the `session` option on the native socket. An fd upgrade assigns
`_handle` after `open`, so `self.setSession()` dropped the option there.

**Two bugs of main that this PR does not fix. An open PR owns each.**
- The native `setSession()` has no check of the handshake state.
`socket.setSession()` in the `handshake` callback of a `Bun.connect`
socket aborts the process (exit 134, release build of main). #41671
fixes it in `set_session` in
`src/runtime/socket/tls_socket_functions.rs`, for each caller. It makes
a late `setSession()` throw `Already started.`.
- Over a `Duplex`, TLS inside TLS, or a named pipe, a handshake that
fails is reported as success. A peer that answers the ClientHello with
plaintext gives `'secureConnect'` for `tls.connect({ socket: duplex,
rejectUnauthorized: false })` on main, and `'secure'` for a wrap with
`rejectUnauthorized: false` here. Node gives
`ERR_SSL_WRONG_VERSION_NUMBER`. Over a TCP socket the result is correct.
The stream engine in `src/uws/lib.rs` reports no protocol error. #32929
fixes it there. One more door of the same bug: with `rejectUnauthorized:
true` and the `session` of an earlier verified connection,
`tls.connect({ socket: duplex })` emits `'secureConnect'` with
`authorized` true on main, and a wrap emits `'secure'` with
`ssl.verifyError()` null here. A write after that fails with
`ERR_SOCKET_CLOSED`, and no byte reaches the transport.

Reproduction for the first one (needs a key and a certificate, for
example `test/js/node/tls/fixtures/agent1-*.pem`):

```ts
const server = Bun.listen({ hostname: "127.0.0.1", port: 0, tls: { key, cert }, socket: { data() {}, open() {}, error() {} } });
await Bun.connect({
  hostname: "127.0.0.1", port: server.port, tls: { rejectUnauthorized: false },
  socket: { data() {}, error() {}, handshake(socket) { socket.setSession(socket.getSession()); /* the process aborts here */ } },
});
```

Reproduction for the second one:

```js
const tls = require("tls"), { Duplex } = require("stream");
let answered = false;
const raw = new Duplex({
  read() {},
  write(chunk, encoding, callback) {
    callback();
    if (!answered) { answered = true; setImmediate(() => this.push(Buffer.from("HTTP/1.1 400 Bad Request\r\n\r\n"))); }
  },
});
const socket = tls.connect({ socket: raw, rejectUnauthorized: false });
socket.on("secureConnect", () => console.log("secureConnect")); // main prints this
socket.on("error", error => console.log(error.code)); // node prints ERR_SSL_WRONG_VERSION_NUMBER
```

**Gaps that this PR does not close.** Each one also exists on main for
`tls.connect({ socket })`, with the same result.

| shape | node | this PR | owner |
| --- | --- | --- | --- |
| `end()` or `destroySoon()` before the socket connects | waits for
`'connect'`, then sends the FIN | `'finish'` at once, no FIN | #42339 |
| refused connection under a wrap | `'_tlsError'`, `'close'` | uncaught
`ECONNREFUSED`, the wrap stays open | #38122 |
| `end()` over a `Duplex` before the handshake completes | runs the
`final()` of the `Duplex` | `'finish'`, no `final()` | #42350 |

A wrapped `Duplex` that fails when it is read was in this list. #42235
landed, and the wrap now reports `'_tlsError'` and then `'close'`, as
node does (measured on d31efd7).

**Inherited options.** `kUpgradeClientTLS` passed a plain `{ socket,
servername }` object to `Socket.prototype.connect`, and that function
reads `rejectUnauthorized` through the prototype chain. With
`Object.prototype.rejectUnauthorized = false`, the wrap accepted an
untrusted certificate, also with an explicit `rejectUnauthorized: true`.
Commit 6657bc3 passes the decision of the constructor as an own
property, as `tls.connect()` does. Measured on this head under that
pollution: a wrap with default options, with `{}` and with an explicit
`true` rejects, and an own `false` accepts. `new TLSSocket(raw, {
rejectUnauthorized: undefined })` with `NODE_TLS_REJECT_UNAUTHORIZED=0`
rejects.

**`'finish'`.** `new TLSSocket(new PassThrough()).end()` emits
`'finish'` and `'close'` on this head. The shutdown cells do not assert
`'finish'`. A separate check reports that `'finish'` is lost there when
#43962 is applied on top of this PR. This session did not build that
combination.

Cell by cell for the 21-cell matrix of #42330 on the earlier head:
#37664 (comment)

**Releases.** Earlier comments in this thread measured the same failures
on Bun 1.4.0 and 1.4.3. This session measured main only.

**User.** `Connection.prototype._startTLS` in mysql 2.18.1
(`lib/Connection.js`) is the known caller of the client-side
constructor. The replay test matches that function line by line, and
`lib/protocol/sequences/Handshake.js` sends the SSLRequest and starts
TLS with no reply in between. The xmpp report in this thread is for
`tls.connect({ socket })`, a different path. A search of the open and
closed issues finds no report for the constructor.

**Guard design.** #42330 kept the stream as `_handle` and added a guard
at 2 of the 6 places that call it as a native handle.

**Signatures on main.** `destroy()` on the wrap fails with `handle.close
is not a function`. `end()`, `end(cb)` and `destroySoon()` throw
`socket.shutdown is not a function` from `process.nextTick`.

**Tests.** All are in `test/js/node/tls/node-tls-connect.test.ts`, block
`new tls.TLSSocket(socket) on the client side`.
- Four reports come from `node-tls-client-wrap-fixture.mjs`. Bun calls
its functions in the test process. Node runs the same file as a script.
The expected report is the same for both.
- `shutdown`: 16 cells. The methods are `end()`, `end(cb)`,
`destroySoon()` and `destroy()`. The streams are a connected, a
connecting and a never-connected `net.Socket`, and a `Duplex`. Each cell
calls the method and then `destroy()`. It asserts no throw, no `'error'`
and `'close'`. The cells run together. On main each cell fails with
`socket.shutdown is not a function` or `handle.close is not a function`.
- `mysql`: the calls of `Connection.prototype._startTLS` in mysql
2.18.1, in the driver's order and at its time. The driver writes the
SSLRequest and starts TLS in the same turn, and the server sends no
reply in between. Three configurations: `rejectUnauthorized: false`, the
CA of the server, no CA. `onSecure` runs one time in each.
  - `peerCloses`: the peer closes when the ClientHello arrives.
- `session`: the `session` option on the three paths, and `setSession()`
before the socket connects. Each one resumes.
- Both sides of `rejectUnauthorized` run in the test process only,
because node accepts in each case. `unlike node, an untrusted
certificate destroys the wrap with the verify error` has one case for
default options and one for `true`. `with rejectUnauthorized: false,
'secure' fires for an untrusted certificate and a write goes out over
TLS` is the other side. `NODE_TLS_REJECT_UNAUTHORIZED=0 turns the
default off, as for tls.connect()` pins the environment variable.
- `an inherited rejectUnauthorized cannot turn the check of a wrap off`
runs in a child process with `Object.prototype.rejectUnauthorized =
false`: default options and an own `true` reject, an own `false`
accepts. It fails on d31efd7. ``an own `rejectUnauthorized:
undefined` still rejects with NODE_TLS_REJECT_UNAUTHORIZED=0, as for
tls.connect()`` pins that rule.
- `setSession() on a wrap has no effect: it does not abort the process
and does not throw` runs in a child process, because the failure is a
process abort. Without the check it gets exit code 134. No test covers a
late `setSession()` on a `tls.connect()` socket: it aborts the process
until #41671 lands.
- On main (canary 367d939, release build), 16 of the 21 tests in the
block fail. 8 fail at once, and 8 fail by the timeout, because main
starts no handshake. The 5 that pass are the http2-wrapper guard and the
4 rows that run node.
- The SNI test fails when only the `servername` argument is reverted
(`Expected: "sni.example"`, `Received: undefined`).

**Cost for callers that never wrap a socket,** from the diff:
- per `net.Socket`: one more property store in the constructor.
- per TLS `connect()`, per client handshake and per `setSession()`: one
more property read and branch.
- per `internalConnect` and `internalConnectMultiple`: two property
reads and branches fewer. Each `[buntls]` options object has one
property fewer.
- `tls.connect({ socket })` puts the same bytes on the wire as on main
(1452).
- This session did not measure instructions, syscalls or binary size:
`perf`, `valgrind`, `strace` and `bloaty` are not in the test container.
A separate differential check of d31efd7 merged onto main reports
equal instruction counts: 10,162,756 (main) and 10,159,922 (this PR) for
each TLS connection, and 2,195 and 2,200 for `new net.Socket()`.

**Suites run with a debug build of this head.**
- On the head a460a9d: `test/js/node/tls/node-tls-connect.test.ts`
gives 107 pass, 18 skip, 0 fail with a 30 s limit, in 2 of 2 runs. With
the default 5 s limit, 4 to 8 tests reach the timeout in each run on
this machine, and the set differs from run to run. Most of them came
from main. The load average was 450 to 970 on 16 cores.
- One of those tests from main (`server write() and end(data) from
inside ALPNCallback`) takes the same time with the source of main and
with this PR: 3.9 to 6.4 s and 3.8 to 6.0 s, 10 runs each.
- `tsc --noEmit -p src/js/tsconfig.json` and `bun lint` pass on
a460a9d.
- The suites below ran on the head c81cee3, before the merge of main.
- `test/js/node/tls/` (28 files): 2 failures in each run, and this
change causes neither. `SNICallback runs even when the requested
servername matches the bind hostname` fails on the release build of main
too. `concurrent Workers all see the same CA certificate lists` fails 5
of 5 times with the `net.ts` and `tls.ts` of main on the same debug
build. In the last run the machine was overloaded, and 2 more tests
reached the 5 s timeout. Both pass alone in 3 of 3 runs, and neither
builds a client-side wrap.
- `test-tls-*`, `test-https-*`, `test-net-*`, `test-http2-*` in
`test/js/node/test/parallel` (657 files): no failure from this change.
10 files fail on main too (`test-https-proxy-request*.mjs`,
`test-https-request-proxy-post.mjs`,
`test-tls-client-allow-partial-trust-chain.js`). `test-https-timeout.js`
hangs on a debug build, with the source of main too.
- `test/js/bun/net/socket.test.ts`: 94 pass, 1 fail. The failure needs
DNS for `www.example.com` and fails on main too.

</details>

<!-- robobun:evidence:begin -->

---

**[human-review]** gate passed · iteration 0 · 5 files touched

<details><summary>fails on main (without fix)</summary>

```console
ASAN without fix: 16 failed, 18 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/node/tls/node-tls-connect.test.ts
bun test v1.4.3 (367d939)

test/js/node/tls/node-tls-connect.test.ts:
(pass) should have checkServerIdentity [3.32ms]
(pass) should thow ECONNRESET if FIN is received before handshake [351.98ms]
(pass) initializes authorizationError to null in the TLSSocket constructor [9.71ms]
(pass) setMaxSendFragment mirrors OpenSSL's [512, 16384] acceptance without throwing [175.18ms]
(pass) should be able to grab the JSStreamSocket constructor [18.49ms]
(skip) tls.connect > should work with alpnProtocols
(pass) tls.connect > Bun.serve() should work with tls and Bun.file() [114.28ms]
(pass) tls.connect > should have peer certificate when using self asign certificate [269.78ms]
(skip) tls.connect > should have peer certificate
(skip) tls.connect > getCipher, getProtocol, getEphemeralKeyInfo, getSharedSigalgs, getSession, exportKeyingMaterial and isSessionReused should work
(skip) tls.connect > should process options correctly when connect is called with only options
(skip) tls.connect > should process port 
... (truncated)

release without fix: 34 failed, 18 skipped
bun test v1.4.3-canary.1 (367d939)

test/js/node/tls/node-tls-connect.test.ts:
(pass) should have checkServerIdentity [20.95ms]
(pass) should thow ECONNRESET if FIN is received before handshake [48.67ms]
(pass) initializes authorizationError to null in the TLSSocket constructor [0.39ms]
(pass) setMaxSendFragment mirrors OpenSSL's [512, 16384] acceptance without throwing [5.88ms]
(pass) should be able to grab the JSStreamSocket constructor [0.30ms]
(skip) tls.connect > should work with alpnProtocols
(pass) tls.connect > Bun.serve() should work with tls and Bun.file() [5.44ms]
(pass) tls.connect > should have peer certificate when using self asign certificate [24.26ms]
(skip) tls.connect > should have peer certificate
(skip) tls.connect > getCipher, getProtocol, getEphemeralKeyInfo, getSharedSigalgs, getSession, exportKeyingMaterial and isSessionReused should work
(skip) tls.connect > should process options correctly when connect is called with only options
(skip) tls.connect > should process port and host correctly
(skip) tls.connect > should process port, host, and callback correctly
(skip) tls.connect > should handle the absence of a callback gracefully
(skip) tl
... (truncated)
```

</details>

<details><summary>passes on PR (with fix)</summary>

```console
ASAN with fix: 18 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/node/tls/node-tls-connect.test.ts
bun test v1.4.3 (367d939)

test/js/node/tls/node-tls-connect.test.ts:
(pass) should have checkServerIdentity [3.27ms]
(pass) should thow ECONNRESET if FIN is received before handshake [394.13ms]
(pass) initializes authorizationError to null in the TLSSocket constructor [8.43ms]
(pass) setMaxSendFragment mirrors OpenSSL's [512, 16384] acceptance without throwing [196.56ms]
(pass) should be able to grab the JSStreamSocket constructor [33.22ms]
(skip) tls.connect > should work with alpnProtocols
(pass) tls.connect > Bun.serve() should work with tls and Bun.file() [298.86ms]
(pass) tls.connect > should have peer certificate when using self asign certificate [101.96ms]
(skip) tls.connect > should have peer certificate
(skip) tls.connect > getCipher, getProtocol, getEphemeralKeyInfo, getSharedSigalgs, getSession, exportKeyingMaterial and isSessionReused should work
(skip) tls.connect > should process options correctly when connect is called with only options
(skip) tls.connect > should process port 
... (truncated)

release with fix: 18 skipped
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped)
  target       linux-x64-gnu
  build type   Release
  build dir    ./build/release
  revision     d31efd7
  features     lto, baseline

23 deps, 136 codegen, 1176 objects in 6018ms

ninja: Entering directory `/workspace/bun/build/release'
[1/4] fetch lolhtml
[lolhtml] up to date
[2/4] fetch rust-argon2
[rust-argon2] up to date
[2/4] cargo plan → /workspace/bun/build/release/rust-target/plan.json
244 units: 172 lib, 16 proc-macro (host), 19 custom-build (host), 15 run custom-build, 17 lib (host), 4 run custom-build (host), 1 rlib
[3/4] reconfigure
[1/1499] mkdir stamps
[2/1499] mkdir codegen
[3/1499] install /workspace/bun
bun install v1.4.3-canary.1 (367d939)

Checked 26 installs across 65 packages (no changes) [231.00ms]
[4/1499] rustc unicode_xid 
[5/1499] rustc heck 
[6/1499] rustc build_script_build 
[7/1499] rustc build_script_build 
[8/1499] rustc unicode_ident 
[9/1499] rustc build_script_build 
[10/1499] rustc build_script_build 
[11/1499] install /workspace/bun/packages/bun-error
bun install v1.4.3-canary.1 (367d939)

Checked 1 install across 2 packages (no changes
... (truncated)
```

</details>

<details><summary>diff hotspot</summary>

```
src/js/internal/net/symbols.ts                    |   2 +
 src/js/node/net.ts                                |  68 ++--
 src/js/node/tls.ts                                |  47 +--
 test/js/node/tls/node-tls-client-wrap-fixture.mjs | 387 ++++++++++++++++++++++
 test/js/node/tls/node-tls-connect.test.ts         | 356 +++++++++++++++++++-
 5 files changed, 806 insertions(+), 54 deletions(-)
```

</details>

**gate history** · 2 passed · 0 rejected · iteration 0

<details><summary>evidence per changed file</summary>

```
file                                               reads  edits  tests
src/js/internal/net/symbols.ts                         0      0     72
src/js/node/net.ts                                     8      0     73
src/js/node/tls.ts                                     1      0     74
test/js/node/tls/node-tls-client-wrap-fixture.mjs      2      3     77
test/js/node/tls/node-tls-connect.test.ts              0      0     69
```

</details>

<!-- robobun:evidence:end -->

### Problem
- A TLS 1.2 server can kill a bun process that calls `fetch()` twice. It
renegotiates on the idle keep-alive connection, and the next request
that takes the pooled socket dies: `panic: abort() called`, stack
`SSL_set_session` <- `session_cache::install` <- `HTTPClient::on_open`.
Regression in 1.4.0.
- `on_open` (`src/http/lib.rs`) runs per request. Its TLS setup was
guarded by `SSL_is_init_finished(ssl) == 0`, also true during a
renegotiation, so it offered the cached session again. BoringSSL aborts
on that.

### Fix
- The TLS setup (SNI, ALPN, inline reject, session offer) becomes
`configure_tls`. Only `on_connect` calls it, the open callback of a new
connection. The guard is gone.
- Correct because uSockets starts the handshake after that callback
returns, and only a new connection takes that path.
- Verified: `test/js/web/fetch/fetch.tls.test.ts` (new test, fails on
1.4.3-canary). Also ran the fetch-keepalive, fetch-session, proxy and
tls renegotiation suites.

### Background
- fetch parks idle connections in a pool and caches one TLS session per
origin (#36598). `SSL_set_session` offers it, legal only before a
handshake starts.
- A renegotiation is a second handshake on a live TLS 1.2 connection,
started by the server.
- Considered a guard in `session_cache::install` and a check at pool
pickup. Both leave per-connection work on the per-request path.

### Downsides
- A request that takes a socket mid-renegotiation still stalls until its
timeout: uSockets does not retry the parked write (#37094). A `todo`
test records it.
- Cost, release builds: a new TLS connection goes from 1,427 to 1,415
instructions, a pooled request from 5,146 to 5,123. Text grows by 1,024
bytes. The stripped binary keeps its size.

<details><summary>Notes</summary>

**How to reach it.** No user code is needed beyond two `fetch()` calls
to one HTTPS origin with verification on (the default). The server
decides the rest. It does not have to withhold anything: a server that
answers and then calls `renegotiate()` is enough when the second request
starts inside the renegotiation. A server that never finishes the
renegotiation keeps the window open for as long as it likes.

**Why the guard was wrong.** `SSL_in_init()` is true whenever a
handshake object exists and is not finalized. That covers the time
before the first handshake step and the whole of a renegotiation.
uSockets allows a client renegotiation (`ssl_renegotiate_explicit`) and
runs it from its `SSL_read` loop, so the pool's idle data handler never
sees the HelloRequest and the socket stays parked while it renegotiates.

**What else the old block did to a renegotiating pooled socket.** It set
SNI and ALPN again. `session_cache::install` took the cached session out
of the cache before it offered it, so the next new connection could not
resume. It replaced the armed session sink with an unarmed one. The new
test checks the second point: after the pooled pickup, a new connection
still resumes the cached session.

**The test.** `fetch.tls.renegotiation-peer-fixture.mjs` runs under
Node, because BoringSSL cannot send a HelloRequest. It is a TLS 1.2
keep-alive origin behind a TCP relay that can hold the client's bytes,
plus a plain HTTP control server. The client fixture parks a connection,
asks the origin to renegotiate, and gets the answer only when the relay
holds the client's renegotiation ClientHello. Then it starts the request
that takes the pooled socket. A control request queued behind it on the
HTTP thread proves that the pickup ran. The test uses no timer.

**Measured, linux x64.**
- 1.4.3-canary.1 (`367d939d9`), release: the new test fails. The client
prints `panic: abort() called` at the pooled pickup.
- Debug build with ASAN of main `468efacace` without the change: the
client exits with SIGABRT at the pooled pickup.
- This branch, debug build with ASAN: the new test passes.
`fetch.tls.test.ts` (62 pass, 1 todo), `fetch-keepalive.test.ts` (49),
`fetch-session.test.ts` (34), `test/js/bun/http/proxy.test.ts` (97) and
`test/js/node/tls/renegotiation.test.ts` (21) pass. With `--todo`, the
todo test times out, as expected. `fetch-keepalive.test.ts` needed a
second run with a longer per-test timeout: four tests hit the 5 s limit
on the loaded build machine.
- Without a relay (the origin answers, then renegotiates, and the client
waits 1, 2 or 3 ms and fetches again), release builds, 5 runs per wait:
main `80de08a1db` aborts in 13 of 15 runs. This branch aborts in 0 of
15.

**What stays.** In 12 of those 15 runs on this branch the second request
does not get an answer. The server reports that the renegotiation ended,
and the request ends in a timeout. (Of the other 3, one got its answer
and two failed with `EPROTO`, which main also shows in this cell.) The
request write parks while the handshake runs, and uSockets dispatches
the writable event only in its `HANDSHAKE_COMPLETED` state, which a
renegotiation leaves until application data arrives. That is a separate
defect in `packages/bun-usockets/src/crypto/openssl.c`, and #37094 has a
fix for it. It does not come from the session cache: it also occurs with
`BUN_FEATURE_FLAG_DISABLE_FETCH_TLS_SESSION_CACHE=1`. The todo test next
to the new test awaits that request, so it flips when the write is
retried.

**Cost numbers.** Release builds of main `80de08a1db` and of this
branch's source on the same commit.
- Instructions from entry to return, nested calls included, counted with
gdb single-steps. 3 runs, 3 consecutive calls per run.
- Open callback of a new TLS connection
(`Trampolines<uws_handlers::HTTPClient<true>>::on_open`): 1,427 on main,
1,415 here. All 9 calls of each build agree.
- `HTTPContext<true>::connect` for a pooled TLS request, sixth request
of the process: 5,146, 5,160, 5,146 on main and 5,123, 5,118, 5,123
here. Later requests vary more from run to run: 6,617 to 6,762 on main,
6,585 to 6,723 here.
- `session_cache::install` calls: 1 per 1,000 keep-alive requests and
100 per 100 new connections, on both builds.
- Size: `bun-profile` text is 80,727,274 bytes on main and 80,728,298
here (+1,024). The stripped `bun` is 80,868,936 bytes on both. Symbols:
`HTTPClient::on_open::<true>` 1,474 to 280 bytes,
`HTTPContext<true>::connect` 5,283 to 5,798, the open callback 375 to
1,582. The TLS block is now part of the open callback, and the compiler
inlines the smaller `on_open` at the three pool reuse sites.
- Tools: gdb 16.3, `llvm-nm`, `llvm-size`. `perf`, `valgrind` and
`bloaty` are not installed on the machine.

**Related.** #41671 covers the other way into the same BoringSSL abort,
`socket.setSession()` after the handshake started. This change does not
depend on it.

**Other designs.**
- A guard in `session_cache::install`: it stops the abort, but the
cached session is still taken out of the cache and the sink is still
replaced.
- A stricter check in `on_open`: BoringSSL has no query for "the
handshake has not started", so it needs a uSockets accessor or new
per-socket state, and one branch stays on every pooled request.
- Skip a socket that is mid-handshake at pool pickup: the abort stops
only because `on_open` is not reached with such a socket. It also
changes which requests reuse a connection.
- Pass SNI, ALPN and the session to uSockets at connect time: a larger
change across every TLS client. It is not needed to remove this defect.

**Not run locally.** Windows and macOS.

</details>

BoringSSL's SSL_set_session abort()s when the handshake has started, so any
late socket.setSession(validSession) killed the process (exit 134) on
node:tls clients and servers, TLS over a Duplex, Bun.connect, Bun.listen and
both upgradeTLS halves.

set_session now returns undefined, as Node does, for a server SSL or once the
client random is filled: do_start_connect fills it right before it moves the
handshake off its initial state and nothing clears it again, so it also covers
a finished handshake and a renegotiation. The JS guard for standalone wraps is
subsumed and removed.

BoringSSL's SSL_set_session abort()s when the handshake has started, so any
late socket.setSession(validSession) killed the process (exit 134) on
node:tls clients and servers, TLS over a Duplex, Bun.connect, Bun.listen and
both upgradeTLS halves.

set_session now returns undefined, as Node does, for a server SSL or once the
client random is filled: do_start_connect fills it right before it moves the
handshake off its initial state and nothing clears it again, so it also covers
a finished handshake and a renegotiation. The JS guard for standalone wraps is
subsumed and removed.

BoringSSL's SSL_set_session abort()s when the handshake has started, so any
late socket.setSession(validSession) killed the process (exit 134) on
node:tls clients and servers, TLS over a Duplex, Bun.connect, Bun.listen and
both upgradeTLS halves.

set_session now returns undefined, as Node does, for a server SSL or once the
client random is filled: do_start_connect fills it right before it moves the
handshake off its initial state and nothing clears it again, so it also covers
a finished handshake and a renegotiation. The JS guard for standalone wraps is
subsumed and removed.

BoringSSL's SSL_set_session abort()s when the handshake has started, so any
late socket.setSession(validSession) killed the process (exit 134) on
node:tls clients and servers, TLS over a Duplex, Bun.connect, Bun.listen and
both upgradeTLS halves.

set_session now returns undefined, as Node does, for a server SSL or once the
client random is filled: do_start_connect fills it right before it moves the
handshake off its initial state and nothing clears it again, so it also covers
a finished handshake and a renegotiation. The JS guard for standalone wraps is
subsumed and removed.

…ps, WebSocket, SQL) (#44618)

### What does this PR do?

Consolidates the open TLS pull requests into one. Each was reproduced on
`main` and, for `node:*` behavior, on Node v26.3.0 first. About a third
are ported as written, the rest are rewritten smaller or merged into one
fix where several PRs patched the same cause. One commit per fix, so it
can be read commit by commit.

Fixes #43520, fixes #31396, fixes #43635, fixes #37193, fixes #43846,
fixes #17932, fixes #41061, fixes #36887, fixes #31810, fixes #35240,
fixes #32234, fixes #44365, fixes #43807, fixes #42280, fixes #44517.
Addresses #41856 (SNI and `servername`; not `checkServerIdentity` for
SQL), #24845 (the spin is gone, shown with fault injection on Linux; not
run on macOS), #19754 (node-fetch forwards the agent's TLS options; the
Kubernetes client itself was not run).

#### The ones that matter most

| | On `main` | PRs |
|---|---|---|
| Client certificate disclosure | `https.request()` with a client
certificate sends it to a server it then refuses (wrong name,
`checkServerIdentity`, `destroy()` in `'secureConnect'`, `terminate()`
in `handshake`). A server can force it with a junk record behind its
Finished | #43946 |
| False `authorized` | Over a Duplex, `secureConnect` with `authorized
=== true` for a peer that failed the key proof; `secureConnect` for a
plaintext peer with `rejectUnauthorized: false` | #44422, #32929 |
| Cleartext https | `https.createServer()` without a usable key/cert
answers plain HTTP | #41672, #33539 |
| Revoked client certificates | An https mTLS server never sees `crl`,
so a revoked client is `authorized` | #41641 |
| Pooled sockets | Requests with different client certificates or CAs
share an `https.Agent` socket and session | #42498 |
| Silent plaintext | `tls: [...]` given to `Bun.listen` / `Bun.connect`
is plain TCP | #41490 |
| Server weakened by a client knob | `NODE_TLS_REJECT_UNAUTHORIZED=0`
turns off a server's client-certificate enforcement | #35245 |
| Pins never checked | `WebSocket` never calls `tls.checkServerIdentity`
and ignores `tls.serverName` | #41648 |
| `verify-full` dropped | `PGSSLMODE=verify-*` is lost next to a `TLS_*`
URL variable; `tls: true` sends no SNI | #44498 |
| Crashes | use-after-free from `destroy()` in `ALPNCallback` over a
Duplex; `abort()` on a late `setSession()`; SIGABRT in `fetch` with an
https proxy from the environment and a `Bun.file()` body | #44462,
#41671, #44458 |
| Stream corruption | A TLS `write()` can lose 16 KiB it reported as
written while another socket on the loop is stalled | #44529 |
| Hangs and spins | 100% CPU on a failing `send()`; a fatal `SSL_write`
leaves the socket open forever; `idleTimeout` never sheds a TLS client
that ignores `close_notify` | #34510, #38176, #42336 |
| Wrong certificate (regression since 1.3.14) | Connections accepted
before `stop()` / `close()` get the default certificate and skip their
entry's `requestCert` / `ca` | #42355 |
| Quadratic Duplex / proxy tunnel | Reading one chunk over a Duplex,
CPU: 8 MB 0.88 s → 0.14 s, 16 MB 3.18 s → 0.23 s, 32 MB 11.75 s → 0.39
s; `fetch` upload through CONNECT: 1.7 s → 0.18 s (debug build) | #44464
|

#### By area

- **fd engine, write path** (`openssl.c`, `socket.c`): #42352, #34510 +
#38176 + #42336 as one change, #44529, #44458, #44192. A rejected
`send()` ends the write side only and closes at the next writable event
unless the peer's bytes are still queued (a 413 sent before a reset is
still read). No new per-socket state. Also, on kqueue, **a FIN no longer
ends a socket that waits in the low-priority queue** (`loop.c`): with
more than 5 TLS handshakes at once, a client that ended right after its
handshake could be reset and its server socket report `socket hang up`,
because the eof that the sentinel read knote reports was acted on ahead
of the unread Finished. That is on `main` too (the macOS entry for
`node-tls-server.test.ts` in `test/flaky-tests.txt`: 7 of 48 recent
builds of other branches), and this branch made it likelier (6 of 8
builds), since Finished now leaves in one segment with the close_notify.
- **Error reporting, both engines**: #44422, #32929, #44516, #37094,
#41272 + #42324 + #44223 as one change, #44021, #37472, #43946, #33630.
One channel: a fatal error on an established session is reported, then
**the engine closes the connection itself**, whatever the owner does
with the report. `test/js/bun/net/tls-fatal-error-closes.test.ts`
asserts closed-and-nothing-delivered for every owner (node:tls,
`Bun.connect`, `Bun.listen`, `fetch` direct and through CONNECT,
`Bun.serve`, `WebSocket` direct and through a proxy, Postgres, MySQL,
Valkey, Duplex).
- **Duplex engine** (`SSLWrapper`, `UpgradedDuplex`): #44462, #43529,
#42332, #44464. #43877 + #44394 were in and are **out again**, see
"Worth a look" 5.
- **node:tls wrap lifecycle** (`net.ts`, `tls.ts`): #38007, #38058,
#38028 + #38122 + #38076 as one change (six copies of the attach code
become two helpers), #38311, #39008, #38154, #42340 + #42343 + #42339 +
#42453 as one change, #43791, #42425, #44085, #42683, #39088, #39040,
#40375, and what was still real of #36534.
- **SNI, ALPN, server contexts**: #43080, #42050, #37195 + #43849 as one
change (**one** SNI matcher for TCP and HTTP/3), #42355, #42285, #33253,
part of #37896, part of #37013. A `tls.Server` has one `SSL_CTX`.
- **Verification and options**: #44738, #41490, #37005 + the cwd pin of
#40984, #31811, #43982, #33483 + #35245, #41810, #32235, #44441, #38092.
- **node:tls API and CA store**: #41671, #38145, #32824, #43594, #39997,
#41696, #33534, #34748, #42991, #42996, #42970.
- **node:https, Agent, `ws`, node-fetch**: #41672 (https half), #41641,
#38261, #42498, #44346, #35609, #31397, #42325.
- **WebSocket client**: #41648, #37487 + #43048 as one change.
- **SQL, Redis**: #33666, #41711, #44498, part of #42054.
- **Tests only**: #41426, #40040, #44395, #44016, #37860, #40591,
#44440, #41424.

Found on the way and fixed here: an upload that a TLS 1.2 server
interrupts with a renegotiation never completes on `main` (0 of 32 runs
over `https.request`, `fetch`, `node:tls` and `Bun.connect`: the
renegotiation ClientHello lands inside an application record that is
still unsent, or the socket gets no `drain` again) and completes here,
with two tests from robobun; the fix for #40653 (final flight and first
write in one segment) stopped working whenever another TLS socket on the
loop was stalled, on `main` too; the `tls.Server` prototype pinned the
last server constructed and every `SSL_CTX` it owned;
`Object.create(process.env).NODE_TLS_REJECT_UNAUTHORIZED = "0"` turned
verification off process-wide once a `SHARE_ENV` worker existed; two
debug panics when wrapping a shut-down or still-connecting socket; a
`fetch` POST through a proxy sent its headers twice when the origin
renegotiated; `BlockList` ignored IPv6 zone ids; a test now ties
`root_certs.der` to `certdata.txt`.

#### Behavior changes

- **A server's `ca` without `requestCert` no longer asks for a client
certificate** (`Bun.serve`, `Bun.listen`, HTTP/3, node:tls). It matches
the docs and Node. On `main` such a server refused clients with no
certificate but served any unrelated self-signed one, so it was never
authentication. **Set `requestCert: true` to require a certificate.** A
matrix test pins that `requestCert: true` still refuses no certificate
and an untrusted one on 8 kinds of server, TLS 1.2 and 1.3, with
`NODE_TLS_REJECT_UNAUTHORIZED` unset and `0`.
- `NODE_TLS_REJECT_UNAUTHORIZED=0` no longer relaxes a server.
- `Bun.connect` / `Bun.listen` hear of a fatal TLS error after the
handshake through `error(socket, err)`. With no `error` handler the
socket just closes.
- HTTP/3 server names match like TCP: `*.` covers exactly one label,
case is ignored, a trailing dot is ignored, the last registration of a
name wins.
- `requestCert` on node:https is `=== true`, as in Node.
- An array where a generated options dictionary is expected throws
(`tls: []`, `jest.useFakeTimers([])`).
- `key` / `cert` arrays serve every identity. A client that can use both
gets ECDSA, where `main` served whichever pair came last.
- `ecdhCurve` is forwarded by node:https, `ws` and node-fetch now, so a
group BoringSSL lacks (`X448`) throws there as it already does in
`tls.createServer`.
- A wrapped socket's error is re-emitted on the TLS socket as in Node,
so `raw.destroy(err)` with a listener on `raw` only is uncaught, as in
Node.
- `sql.options.tls` is always an object, never `true`. `RedisClient`
sends SNI.
- `tls: { secureContext }` alone asks for TLS on `Bun.listen` /
`Bun.connect` (it was plain TCP), and a value that is not a
`SecureContext` throws. The context is served as it is: the
`requestCert` / `rejectUnauthorized` it was created with hold whatever
the options next to it say, and `requestCert` in the options over a
context that does not ask throws at `listen()`.
- `tls.DEFAULT_CIPHERS` reaches every client once assigned (`fetch`,
`WebSocket`, `Bun.connect`, `RedisClient`, `Bun.SQL`, `S3Client`, proxy
tunnels) and servers again. A list that selects no cipher throws
`ERR_SSL_NO_CIPHER_MATCH` at the assignment. `fetch.preconnect()` dials
nothing after an assignment.
- The warning for an unreadable `NODE_EXTRA_CA_CERTS` is Node's one
line, without the `warn:` prefix.
- `BUN_CONFIG_WS_CLOSE_TIMEOUT` (default 30 s): how long a `WebSocket`
client waits for the server to close the connection after the closing
handshake.

#### Worth a look in review

1. **#44529**: the kernel-refused remainder of a TLS write moves from
the loop's one slot onto the connection (in the existing rare struct),
so the write BIO never refuses a sealed record. Nothing is allocated on
an unstalled path (200 writes: 0 appends, same `send()` count as
`main`), memory with 16 stalled writers is lower than on `main` (276 KB
vs 340 KB, which `main` holds inside BoringSSL's buffers), `us_socket_t`
stays 80 bytes. It needs a bound on how long a deferred close waits, or
a peer that stops reading pins the fd past `destroy()`:
`US_SSL_CLOSE_AFTER_SPILL_TIMEOUT` is a fixed 10 s, not re-armed on
progress. Separate commits, but the fix that keeps the client
certificate off the wire beside a stalled socket builds on them.
2. **The default name check of node:tls also runs inside the
handshake**, so a wrong-name server gets no client certificate on TLS
1.2 either. JS still runs it after every successful handshake, so a
difference between the two matchers can only refuse. Error objects are
byte-identical.
3. **#44441** widens trust by design: a self-issued leaf whose
`keyUsage` lacks `keyCertSign` (`dotnet dev-certs`) is its own anchor
when the store holds a byte-identical copy. No BoringSSL change. Expired
pin, same subject with another key, wrong EKU and a pinned intermediate
are tested to fail.
4. **#32235** only adds Ed25519 and ECDSA P-521 to the verify list. A
captured ClientHello shows `main`'s list with the two inserted;
`rsa_pkcs1_sha1` stays.

5. **A stream that a TLS socket wraps, when that TLS socket closes.** An
earlier state of this branch lost data here while CI was green (found by
#44709's report): with the peer closing first, 4 of 8 MiB arrived with
TLS in TLS, 4 of 32 MiB on the http2 `emit("connection")` path, and a
`write()` with no `'error'` listener ended the process. Three
Node-parity changes only hold together: destroying the wrapped stream at
the close (#38028 + #38122 + #38076, #38154) is safe only if every write
has really completed (#43877), which in turn needs Node's handling of
the peer's close_notify, which needs half-open sockets that the GC can
collect. So:
- #43877 + #44394 are reverted and reopened. A write over a stream
completes once the stream has taken the ciphertext, as on `main`.
- Until the verdict on the peer lets the session through, the
application cannot have written over it. There the wrapped stream is
destroyed as in Node, with the sessions below it. That keeps the release
of the connection after a failed handshake, a rejected certificate and
an early `destroy()`. The same for an http2 socket the application never
got, and for `resetAndDestroy()`.
- After that it is `main`'s teardown: a `net.Socket` only gets the
engine's `end()`, closes at its peer's FIN, keeps its own timeout and
reports its own errors. Any other stream is destroyed with the TLS
socket.

The regular suites cannot see any of this (999 files were green on every
broken variant), so it was steered by eleven seeded differential fuzzers
run on this build, `main`, Node v26.3.0 and the earlier state: close,
`end()`, `destroy()`, `destroySoon()`, resets, hung and half-open peers,
paused writers, timeouts, two and three sessions deep, over TCP and over
Duplexes, before, at and after the handshake, and http2 requests. See
"How did you verify".

#### Known limits

- `fetch` with a `checkServerIdentity` function still sends the client
certificate (not the request) to a server the function refuses. On TLS
1.2 any verdict a JS callback gives is too late, as in Node.
- `addContext()` / `SNICallback` still do not apply to a server-side
socket on the stream engine (`emit("connection", duplex)`, TLS in TLS,
unflushed writes, named pipes), as on `main`.
- A CA bundled in a pfx extends an explicit `ca` only, for `ws` /
node-fetch / `WebSocket`: the native `ca` can only replace the default
store, and that store keeps `SSL_CERT_FILE` / `SSL_CERT_DIR`.
- P-521 leaves work on TLS 1.3 only. TLS 1.2 needs secp521r1 in every
ClientHello (`it.todo`).
- Once `tls.DEFAULT_CIPHERS` is assigned, `fetch(url, { protocol:
"http3" })` is `HTTP3Unsupported`, as with an explicit `ciphers`.
- `addCACert()` by hand does not extend the chains of a context with
several identities.
- A throwing `ALPNCallback` sends `no_application_protocol` on both
engines. Node sends nothing and its client sees `ECONNRESET`.
- TLS in TLS, peer FIN while the outer handshake runs: the inner socket
gets one `write EPIPE`, where Node gives `ECONNRESET` (`main` gives it
no error at all).
- `@SECLEVEL` in `ciphers` is dropped by the `ws` / node-fetch shims,
which used to ignore `ciphers`. node:tls keeps throwing
`ERR_SSL_INVALID_COMMAND`.
- Beside a stalled TLS socket only the first record (16 KiB) of the
first write leaves with the handshake flight. The rest goes record by
record, which is what bounds the memory of stalled writers.
- After a fatal error on an established session the socket emits
`'error'` and then `'close'`. Node emits `'error'` and leaves the socket
open.
- A paused reader whose own write the kernel rejects loses what it had
not read yet, with an `EPIPE`, as on Node. `main` reports no error there
and delivers it.
- On `main` too: a `Bun.listen` socket without `allowHalfOpen` that has
unsent ciphertext when the client's `shutdown()` arrives loses that
ciphertext (32 KiB), and over plain TCP `end()` with the peer still
sending is a close over unread input, so a reset.
- Differences from both `main` and Node that the differential runs below
found and that stay, all with a peer that aborts: `ECONNRESET` instead
of a clean `'end'` after the socket's own `'finish'` when the peer
destroyed with unread data; under TLS 1.2, a zero-length `write()`
followed by `destroy()` in `'secureConnection'` leaves the client
without `'secureConnect'` (a plain `destroy()` there matches Node); a
TLS 1.2 client that destroys in `'secureConnect'` gets no `'session'`; a
`ClientRequest` whose handshake fails with an alert emits `'error'` and
`'close'` but no `'finish'` (`writableFinished` is true).
- Once `tls.DEFAULT_CIPHERS` is assigned, `fetch.preconnect()` opens
nothing: `fetch()` then uses a context of its own, and a socket warmed
under the default one would never be picked up.
- A TLS `send()` that the kernel refuses outside a `write()` call (the
drain of unsent ciphertext) is reported with the close, as `read EPIPE`
/ `read ECONNRESET`. Node says `write EPIPE`. `main` does not report it
at all.
- Once the application has a session over a `net.Socket` (TLS in TLS,
http2 `emit("connection")`), a peer that never sends its FIN holds that
socket after the TLS socket closed, as on `main`. Node destroys it. Two
tests of #38154 are `todo` for this. Closing it any earlier (at its
`'finish'`, say) makes the kernel drop what it has not sent yet as soon
as the peer's close_notify arrives.
- Plaintext that was queued on a socket before it was wrapped (STARTTLS
with a backlog) is dropped when the TLS socket is destroyed, or its
handshake fails, before the session is accepted. Node drops it too,
except on `destroySoon()`. `main` sends it.
- Over a stream that is no `net.Socket`, `end()` can still cut what that
stream has buffered, and there is no backpressure, both as on `main`
(#43877).
- `tls.secureContext` (the undocumented door node:tls uses) is not read
by a Windows named pipe listener, which builds its context from the
options. On `upgradeTLS({ isServer: true })` the options next to it are
the policy, as with Node's `SetVerifyMode`.
- `selectServerName()` rebuilds the name tree per ClientHello for
injected sockets of a server with `addContext()` entries: 0.4 µs for 1
entry, 3.7 µs for 10, 41 µs for 100, against 631–1111 µs for a
handshake.

#### Not included

Left open, because they need a decision or are not TLS: #43877 + #44394
(see "Worth a look" 5; #43874 stays open with them), #38548, #38591
(both shrink who is trusted), #41589 (`verify-full` vs
`NODE_TLS_REJECT_UNAUTHORIZED=0`), #37197, #41706, #43216, #33487,
#33545, #36707, #32435, #37255, #28691, #40275, #30314 (features),
#38120 (needs the BoringSSL fork, as did #33517, which the stale bot has
closed since), #38529 (needs a Windows measurement), #34342, #38232,
#43089, #44454, #40451, #42710, #44527, #38088, #38093, #41898. #37896,
#42054 and #37013 stay open for the halves not taken.
`http.createServer({ key, cert })` keeps serving TLS on purpose.

One open question: `tls: {}` (an object that names no TLS option) is
plain TCP on `Bun.listen` / `Bun.connect`, here and on `main`. It is the
same trap as `tls: []`, but changing it changes a Bun default, so it is
left alone.

### How did you verify your code works?

- Every new test fails on `main` for the stated reason and passes here,
except guards that pin existing behavior, each shown to fail when its
clause is removed. `node:*` tests also pass on Node v26.3.0; the few
that cannot say which Node version has the behavior.
- 212 test files that touch TLS, sockets, http, http2, fetch, WebSocket,
SQL, Valkey and workers: 6154 pass, 2 fail. Both are seen on `main` too:
`serve.test.ts` "root range port" (the box runs as root), and
`worker_threads.test.ts` "terminate(): nothing of the worker's runs
after the request", which is flaky there and passed in the run below.
- 58 of those files the way the ASAN lane runs them (LeakSanitizer +
`BUN_JSC_validateExceptionChecks`): 58 files, 48 of them with leak
checking, 4132 pass, 3 fail. All three also fail on `main`:
`serve.test.ts` "root range port", `node-net.test.ts` "should not leak
when connect({path}) fails synchronously on a reused handle" (times out
under this environment), `worker_threads.test.ts` "process.exit() with a
shell cp in flight" (a `ShellCpTask` leak).
- 647 vendored `test-tls-*`, `test-https-*`, `test-net-*`,
`test-http2-*`: the only two failures also fail on `main`.
- The SNI matcher was diffed against both old matchers: 3 seeds × 1.23 M
lookups × 3 registration flavours, every difference in one of the
intended classes, TCP and HTTP/3 identical on every lookup.
- The headline rows were also driven by hand with scripts against this
build, `main` and Node v26.3.0: cleartext https, `crl`, `tls: []` / `{
secureContext }`, the `ca` / `requestCert` matrix, the client
certificate on a wrong-name server, late `setSession()`, `destroy()` in
`ALPNCallback`, `[rsa, ec]` identities with an intermediate from `ca`,
`WebSocket` `checkServerIdentity`, a corrupted record, the Duplex read
above, `tls.DEFAULT_CIPHERS`.
- The `setSession()` guard was checked against the real `abort()` at 43
handshake states.
- `bun run rust:check-all`: 12 of 12 targets. `tsc`, oxlint, source
lints, prettier, rustfmt, mordant clean.
- usockets' `_Nonnull` is compiled out of debug builds, so 105 of those
files were also run on a local release ASAN build with the CI runner's
environment (92 with leak checking): 4595 pass, 1 fail,
`child_process.test.ts` "spawn reports EPERM after dropping privileges",
which cannot pass as root and fails on `main` too.
- The close of a TLS socket over another stream ("Worth a look" 5):
eleven seeded differential fuzzers, 8,424 scenarios compared, each run
on a release ASAN build of this branch, on `main`, on Node v26.3.0 and
on the earlier state of the branch. Against `main`:
- Data that `main` delivers in full is cut in 5 scenarios, and about 150
that `main` cuts arrive in full. Of the 5, in 2 `main` never notices the
peer's close and keeps the socket for good, 2 call `end()` on the middle
one of three sessions over an in-memory Duplex, and 1 does the same on
Node.
- No dead timeout, no silent reset and no uncaught error that `main`
does not have (4 uncaught errors fewer).
- A socket stays open where `main` closes it in 109, and closes where
`main` keeps it in 295. 92 of the 109 do the same on Node or on the
earlier state (a `destroy()` that an in-memory Duplex does not show its
peer, half-open peers). 14 wait for a peer that paused reading and so
does not read the FIN (#42332's backpressure, as in Node); the socket's
own timeout fires there. 3 are left: one on a 5 ms timer, two with three
sessions over an in-memory Duplex.
- The earlier state of the branch cut data in 173 of the 400 scenarios
of one of them, where `main` cuts none and this cuts none.
- 23 new tests pin what they found. Each earlier attempt at this fix
fails the ones that describe it, the earlier state of the branch fails
7, and all pass on Node.
- After that change: 999 test files on the release ASAN build (20,246
pass; the 11 files that fail need a database, Docker, DNS or a non-root
user, or share a temp directory with a parallel run and pass alone), 61
on the debug build.
- TLS over a file descriptor (`openssl.c`, the path of `fetch`,
`Bun.serve`, `tls.connect`, `Bun.connect`) got the same treatment after
the rebase: seeded differential fuzzers on CI's release build of this
branch, on `main` and, for `node:*`, on Node v26.3.0. Every runtime also
against itself for the noise floor, injected faults and known bugs of
`main` as positive controls, and a difference counts only if it shows in
5 of 5 fresh processes.
- `node:tls` over TCP: 11,500 scenarios (one connection with Node as the
oracle line by line; 2 to 60 connections beside stalled neighbours; raw
peers that break the handshake). HTTPS: about 136,000 runs over
`Bun.serve` + `fetch`, `node:https`, `node:http2` and `wss://`, also
with the two ends in different runtimes. `Bun.connect` / `Bun.listen` /
`upgradeTLS`: 11,500 scenarios and 720 slow connections, with writers
driven by what `write()` returns, beside up to 6 stalled, dripping,
closing or resetting neighbours, and plain TCP as a second oracle. No
crash, hang, duplication, reordering or silent truncation, and no change
in time or in connection reuse.
- They found six things that `main` does better, none of which any test
showed. All are fixed, each with a test that fails on the build before:
what the peer sent lost behind a rejected `send()` (23 scenarios, and an
early HTTPS response lost with only `EPIPE`), the same silently for a
paused reader, `server.close()` never calling back on a half-open server
after a ClientHello and a reset (17), `closeAllConnections()` taking 12
s with a stalled client, `end()` losing up to 1.3 of 4 MiB that
`write()` had reported while the peer still uploads, and `end()` a
little after a stall never closing beside other stalled TLS sockets. The
last two fixes also deliver the 1 to 2 MiB that `main` loses there, and
close the socket that `main` keeps for good without such neighbours.
- All of them again after every fix, on CI's release build of it. That
caught one regression of a fix itself (a reader stopped for backpressure
lost 86,385 bytes, 1 of 6,000 scenarios), fixed too. On the last build:
scenarios that lose data where `main` does not 23 → 2, and Node loses it
in both, with the same `EPIPE`; `server.close()` that never calls back
17 → 0; connections held 4 → 0; requests that end in an error only where
`main` has a response 6 → 0. With a Node server in another process, a
request ends in an error only in 8 and 10 of 1,500 scenarios here, 5 and
3 on `main`, 10 with Node as the client.
- `Bun.connect` / `Bun.listen` on the last build against `main`, in
scenarios: hangs 0 against 1,031, sockets and fds never released 0
against 965, corrupted data 0 against 345, `abort()` 0 against 26
(`setSession()` after the handshake), writers that never close 0 against
101 of 720 connections. No kind of failure shows here and not on `main`.
About a third of the slow connections close later than on `main`, in 1
to 16 s instead of at once, waiting for unsent ciphertext or for the
peer's close_notify, and 79 more of them deliver all that `write()`
reported. RSS and time with 16 to 256 stalled writers are the same.
- What they found that `main` does worse: a `WebSocket` that calls
`close()` with sends pending loses messages in 81 of 999 scenarios (0
here), 37 server sockets left open, 10 `server.close()` that never call
back, 20 write callbacks that never run.
- The kqueue fix cannot be run on Linux. The `connectionListener` count
test now says what became of a missing connection, which is how the
cause was found (`'tlsClientError'` "socket hang up", then `read
ECONNRESET` at the client of the same port, after its
`'secureConnect'`). On macOS x64 it failed every attempt of the three
builds before the fix and passed at the first attempt of the build with
it.
- Windows and macOS were only run by CI. Four new tests asserted what
only the Linux kernel does (a FIN read ahead of a reset, unread bytes
surviving a reset, loopback buffer sizes, `fstat()` on a socket) and now
say so per platform.

---------

Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: robobun <117481402+robobun@users.noreply.github.com>